In conventional systems, a client wishing to use SIP to establish a call will be configured to contact a SIP server in order to find out the IP address to send media to. This may be the address of a media forwarding element, or it may be the final destination media address of the called party (client). In cases where the communication channel does traverse a media forwarding element, the client sends media packets to that media forwarding element, and the media forwarding element is responsible for forwarding those packets onwards towards the called party. In other words, the session initiation protocol provides the client with the IP address of the media forwarding element that the client should use to conduct a call.
In this way, the client can establish a unicast channel of communication (i.e. messages are sent to a single network destination identified by a unique address) with the media forwarding element. If the media forwarding element is unavailable or becomes unavailable during the course of an exchange of packets with the client, packets to/from the client will not be delivered. This may result in call failure.
Steps may be taken to prevent this, such as making available an alternative media forwarding element which can be used to establish, re-establish, or take over and maintain a call. This could, for example, involve the client being configured to store or obtain the IP address of the alternative media forwarding element so that it can establish a unicast channel of communication with the alternative media forwarding element if the original media forwarding element fails, or causing a SIP signalling element to notify the client, when the first media forwarding element has failed, that the alternative media forwarding element can take over the call. In some implementations, SIP signalling elements and media forwarding elements may be distinct from one another. In other implementations, media forwarding elements may be able to function as SIP signalling elements. If the alternative media forwarding element of the above example is able to function as a SIP signalling element, it may inform the client that it can take over the call.
However, conventional SIP implementations do not provide a mechanism for indicating an alternative media forwarding address ahead of time, i.e. before a first media forwarding element fails. As a consequence, a conventional SIP client may not be able to obtain in advance and store an alternative media forwarding address.
Furthermore, the SIP client may be firewalled to block data packets coming from unknown and/or unapproved IP addresses. Thus an alternative media forwarding element may not be able to notify the SIP client that the alternative media forwarding element can take over the call, or send any media or signalling data to the client, if the alternative media forwarding element has a different IP address from the IP address of the failed media forwarding element. The client would instead need to send a “re-INVITE” request to obtain a new media forwarding address for the call and amend or otherwise overcome its firewall configuration accordingly before it would be able to receive data packets from the alternative media forwarding element. A firewall configuration may be overcome by sending a communication out through the firewall (from the client towards the alternative media forwarding element) and establishing a new association (e.g. a UDP association) between the client and the alternative media forwarding element. These or similar steps might also be necessary to overcome any issues with network address translation (NAT) traversal.
It is therefore difficult to repair a failed SIP call in a timely fashion if different IP addresses are used before and after failure of a media forwarding element. The client would need to detect the failure; re-register with the SIP server/VoIP provider; and send a “re-INVITE” request before it would receive an address for communicating with the alternative media forwarding element. The client would then need to establish a connection with the alternative media forwarding element before the alternative media forwarding element could forward data packets to the client.
Where one media forwarding element fails or becomes unavailable, a large number of clients which were using this element may then need to establish contact with a different media forwarding element. This may lead to an undesirable concentration of traffic over parts of a network, particularly if all the clients in one part of a network are trying to connect to a media forwarding element in a different part of the network, thereby applying additional load to the intervening portions of their network.
The above shows that an alternative media forwarding address can neither be signalled ahead of time nor discovered in response to a failure.
The above-described system utilises unicast addressing where a packet is sent out onto a network destined for a unique IP address. The packet is passed from node to node in an effort to carry the packet to the device associated with that unique IP address. Whilst there are other forms of routing such as multicast (where the originating packet is destined to a set of unique IP addresses) or broadcast (where the packet is transmitted to all possible destinations), these are not appropriate for this kind of communication.
In such a unicast system, a media forwarding element will typically have its own unique IP address. That IP address is not in use by any other elements in the network while the media forwarding element is using the IP address. In the event that the media forwarding element fails, an alternative media forwarding element may assume the unique IP address of the failed media forwarding element and perform media forwarding in the place of the failed media forwarding element. In other words, the unique IP address may be transferred from the failed media forwarding element to the alternative media forwarding element Unicast may therefore be referred to as an “active-standby” model: while the first media forwarding element is active, the second (alternative) media forwarding element is in standby. The second (alternative) media forwarding element becomes active only when the first media forwarding element is unavailable.
There is a further routing technology which is known as anycast, which is sometimes used for service discovery, load balancing and fault recovery. In a network where anycast is deployed, multiple devices may be provided with interfaces having the same IP address. An address such as a DNS name, e.g. sip.server.com, may resolve to this single anycast IP address even though there are multiple instances associated with the IP address. Anycast may therefore be referred to as an “active-active” model: two or more media forwarding elements, for example, may simultaneously use one IP address. The IP address corresponds to the two or more media forwarding elements without uniquely identifying either media forwarding element.
In this way, when a packet is sent to an anycast address, as it is passed from node to node, the node will pass the packet on to the part of the network which it believes will get the packet to the desired address. This will tend to route the packets to the topologically nearest device utilising the anycast IP address. In other words, an effect of using anycast is that user traffic is automatically assigned to nearby server sites. In conjunction with dynamic scaling, the capacity within each site can be adjusted, e.g. in accordance with demand. The packets will tend to be routed to the nearest instance of the anycast address. This will help to balance load as traffic will tend to be routed to the nearest destination having the anycast address rather than having to traverse large distances over the network to get to a server having a specific unicast address.
Similarly, service discovery can be provided using anycast so that a device wishing to identify a service can simply send its request to an anycast address knowing that the actual server receiving the request does not need to be a specific one but rather one that can provide the service discovery. In this way the message will tend to be routed to the nearest device providing the service discovery, which, in addition to the load balancing benefit mentioned above, also helps to minimise the transit time and network bandwidth consumption.
Anycast can also provide a degree of fault recovery in that if one server using the anycast address becomes unavailable, the network will automatically tend to continue to route packets to an alternative server carrying that anycast address.
Overall, the anycast approach can be used to deliver optimal bandwidth usage, minimal network latency, and automatic recovery in the case of network element failure. It can remove the need to maintain large numbers of backup network elements standing idle in case one or more elements fail. Moreover it may allow this to be achieved without firewall and/or NAT traversal issues, since data packets from different network elements using the same anycast address may be permitted through a client firewall that allows data packets from that IP address.